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ABSTRACT 



An open-architecture system and method of posting and paying 
invoices via the Internet permits multiple billers and multiple 
customers to use the system without requiring that customers be 
subscribers. A billing/payments facilitator establishes and 
maintains an interactive website that interacts with a database 
including selected particulars of individual billers and 
individual customers. For each invoice, the facilitator receives 
suitable billing data from a biller and posts the billing data 
on the website for access by the customer identified in the 
invoice. The facilitator notifies the customer that an invoice 
has been posted and provides the customer with a bill 
identification code. The facilitator displays the posted invoice 
to the customer upon receipt of such customer's bill 
identification code. The customer while on-line may authorize 
payment of the invoice by any approved electronic payment method. 
The facilitator may deduct a transaction fee from the amount, the 
balance of which is passed on to the biller. 
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INTERNET BILLING AND PAYMENT SYSTEM 

5 Field of the Invention 

This invention relates to an Internet billing and payment 
system to facilitate billings and payments using the Internet. 

10 Background of the Invention 

A number of commercial transactions occur on the Internet. 
Many Internet-based businesses operate by offering products or 
services for sale on the Internet, and by receiving payment from 

15 users or purchasers typically by way of submission by the user 
or purchaser of credit card information to the provider of goods 
or services, whereupon the credit card is debited and the goods 
and services are provided. Encryption and verification 
procedures have been developed to authenticate amounts billed and 

20 transferred, parties to transactions, and other particulars. 

A number of Internet-based systems exist for consolidating 
bills and transmitting them to a billed customer. Typically, a 
postal, telecommunications or financial institution will gather 

25 together bills from various billing entities (billers), and allow 
Internet portal access to recognized customers to pay the total 
amount owing, or a portion thereof. Such payment is made to the 
bill consolidator service provider, who then distributes the 
amount received to the billers. In such arrangements, the 

30 individual billers (typically retailers) and the billed customers 
do not have a direct communications or payment link - the link 
with either exists only through the bill consolidator. Credit 
card companies may function in this manner. A representative 
prior patent directed to computerized billing and payment 

35 authorization systems is U.S. patent no. 5943656 granted to 
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Crooks et al. on 24 August 1999. An alternative bill 
consolidation and payment aggregation and settlement system is 
described in U.S. Patent 5978780 granted to Watson on 2 November 
1999. 

5 

The principal problem with bill consolidation processes and 
facilities of the foregoing sort is that only a limited number 
of subscribers may use the Internet-based system, and those 
subscribers do not have any direct communication or transaction 

10 links with the billing entities - rather, all transactions occur 
with the bill consolidator . This kind of billing consolidation 
procedure and facility cannot be used by either billing entities 
or billed entities to communicate with one another and arrange 
submission of invoices or payment of invoices directly to one 

15 another. Furthermore, the limited subscriber list of bill 
consolidators means that the bill consolidators ' facilities 
cannot be easily used by the general public via the Internet. 

Summary of the Invention 

20 

According to the present invention, an open billing 
architecture is provided that enables any billing party to 
communicate an invoice or bill via the billing and payment 
facilitator's website to any customer (or at least to any 

25 customer having an Internet address), without requiring either 
party to be a subscriber to the billing service facilitator's 
system, and without restrictive funnelling of the various 
transactions through a bill consolidator or the like. The term 
"open architecture" is used to signify that the system is 

30 available to many users, be they billers or customers or both, 
without the need to record any users as subscribers to the 
system. 



According to the invention, a centralized billing service 
35 facilitator operating a website (hereinafter "facilitator") 
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permits a biller to present its bill or invoice as a discrete 
payable invoice directly to the billed customer. An invoice 
posting procedure according to the invention is described below. 
The principal proviso is, of course, that the billed customer be 
reachable by a suitable communications link, which as a practical 
matter implies that the customer should have an Internet address. 
The billed customer is alerted by an incoming e-mail message or 
equivalent notice (e.g. by pager) that the biller has sent the 
bill to the facilitator. The customer then may access the 
facilitator's website, review the invoice, and if the particulars 
are correct, arrange payment of the invoice via the facilitator. 
The facilitator passes on the received amount to the biller, less 
a transaction fee unless some other arrangement is in place for 
compensating the facilitator. Payment may be effected by credit 
card, by debiting a bank account, or by any other means 
acceptable to the parties to the transaction. 

By proceeding in this way, both the biller and the customer 
may avoid the delays and expense of using the postal service. 

The system presumably would, of course, be subject to the 
usual security and privacy measures available to protect Internet 
sites and transactions; firewall protection against hackers and 
against "denial of service" bombardment would be established, as 
would any other form of Internet protection applicable to 
businesses operating on the Internet. Future security and 
privacy protection measures would presumably be applied as and 
when available and effective. 

The entire system can optionally function without passwords 
and without subscribers, although purchasers may be offered a 
subscriber option that makes available such additional services 
as automatic access to a subscriber's designated bank account or 
the like, and billers may be offered a subscriber option that 
further facilitates various aspects of the processing of invoice 
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posting and payments. Further, billers would be expected by- 
direct agreement or by implication from the fact of using the 
facilitator' s services to agree with the facilitator that the of 
the facilitator may extract a transaction fee; this condition of 
5 service may be implicit in the election by the biller to use the 
facilities of the website operated by the facilitator. 

In greater particularity, the bill-posting and bill-payment 
process would work according to one aspect of the invention as 
10 follows, the posting procedure of course preceding the payment 
procedure : 

A first on-line Internet invoice-posting session occurs 
between the biller and the facilitator; a second on-line 

15 Internet invoice-review-and-payment session occurs between the 
customer (billed party) and the facilitator. In both sessions, 
the facilitator functions in reactive mode; the initiating party 
for the first session is the biller and the initiating party for 
the second session is the customer. These sessions are premised 

20 on the maintenance by the billing service facilitator of a 
database that itself contains certain specified information or 
is linked to one or more other databases containing such 
information. The information expected to be required for each 
invoice would be, for example, entered in the following fields: 

25 1. Biller' s name, address, and phone number, and possibly an 
account number and/or password 

2. Date posted (generated automatically) 

3. Invoice number 

4 . Name of customer 

30 5. Particulars of customer notification method, normally e- 
mail 

6. Total amount due 

7. Due date 

8. Bank account to which to deposit the payment (optional) 

35 
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Note that the facilitator from a linked database may 
automatically generate various of the field data entries for the 
invoice database, notably the biller' s name and bank account, if 
the biller is a subscriber of the facilitator. The facilitator 
5 could if so directed by the biller generate automatically a 
series of invoice numbers for successive invoices transmitted by 
a given biller. Similarly, the customer's name and e-mail address 
can be generated automatically if the customer is a previously 
identified customer of the biller or is a subscriber of the 
10 facilitator. 

The first (invoice-posting) session occurs as follows: 
a. The biller logs on to or otherwise accesses the 
facilitator's web site. 
15 b. The biller submits an invoice to the facilitator. (Note 
that the facilitator should preferably be able to upload 
•pdf, . gif, .jpg, or other suitable formatted invoice 
details files, possibly saved with file extension .bil.) 
c. The facilitator displays to the biller on the facilitator's 
20 website an acknowledgment of the bill, optionally with a 

confirmation code accessible to the biller. 

Step (a) above may require the biller to submit sufficient input 
information (possibly merely a log-on identification code and a 
25 password) that enables the facilitator to compare the information 
against stored and registered data maintained in the 
facilitator's biller database. 

Step (b) above may require the biller to submit sufficient input 
30 information (possibly merely a customer identification code) that 
enables the facilitator to compare the information against stored 
and registered data maintained in the facilitator's customer 
database . 

35 The completion of the foregoing steps results in the 
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creation of a database record for the invoice in the 
facilitator's invoice database that will contain data 
corresponding to each of the fields mentioned above, or some 
other suitable set of selected fields appropriate to the kind of 
5 transaction to which the invoice relates. 

Next, the facilitator notifies the customer via e-mail of 
the existence of the bill or invoice and of a bill identification 
code required to enable the customer to retrieve particulars of 
10 the invoice. The bill identification code may preferably be 
automatically generated by the facilitator but conceivably could 
be provided by the biller as a further item of invoice-related 
data . 

Once the customer is aware of the existence of the invoice 
and knows the bill identification code for the invoice, the 
customer may at will initiate the second (invoice review and 
payment) on-line session with the facilitator. The second on- 
line session proceeds as follows: 

a. The customer accesses the facilitator's website. 

b. Using the bill identification code, the customer selects a 
display of the invoice and may optionally download the 
invoice to the customer's computer. 

c. Optionally, the customer elects whether to pay the invoice 
only in part. (Of course, the Customer may elect not to 
pay the invoice at all, and may log off the website at any 
time during the session prior to authorizing payment.) 

d. The customer specifies how to pay the invoice - typically 
by credit card or debit card, but alternatively, if a 
subscriber of the facilitator, by any other means agreed 
upon, such as digital cash payments or direct bank account 
debiting, possibly from a selection of available bank 
accounts . 

e. The customer may optionally set a specific date on which 
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payment will occur. If the biller or facilitator so 
requires, or as a default, payment will occur automatically 
on the date of the session. 

If the payment involves an additional transfer between 
customer bank accounts, then the billing service 
facilitator may display the amount of any additional 
transaction fee and presumably will provide a means of 
obtaining approval from the customer before effecting the 
transfer of funds. 

Payment follows pursuant to the manner of payment elected 
by the customer, upon the customer's entry of payment 
approval . 

The foregoing series of steps pursuant to one or both 
15 sessions may be subjected routinely to suitable security and 
other safeguards. For example, the transaction can be processed 
in part through an electronic payments accreditation service such 
as the ClearCommerce service available from clearcommerce.com. 

20 Once the payment of the invoice has occurred, the 

facilitator displays on its website a confirmation number for 
access by the biller to the particulars of the payment. The next 
time that the biller accesses the facilitator's website, the 
biller may check the status of invoices previously posted on the 

25 website, and will note any confirmation data posted. The biller 
may also note the status of unpaid invoices, and may send 
reminders directly via e-mail to the various customers in default 
of payment, or may arrange to have the facilitator do so if the 
latter elects to provide a reminder service. 

30 

Both billers and customers may optionally become subscribers 
of the facilitator. Subscribers save time and effort by avoiding 
having to enter the same data many times. Each subscribing 
biller' s computer system can be connected to the facilitator's 
35 system to generate invoices automatically. 
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The data to be gathered by the facilitator from subscribers, 
when they first become subscribers, may include the following: 

Biller's initial data: 

1. Company name, telephone number, address, e-mail address, 
etc . 

2. Fiscal year-end 

3 . Bank account (s) 

4. Facilitator account or reference number (assigned by the 
facilitator) 

5. Password for the subscriber service and/or each of the 
biller's bank accounts (selected by the biller but known to 
the facilitator) 

6. Names, e-mail addresses, etc. of all customers designated 
by the biller, and their bill notification method 
(preferably e-mail) 

7. (optionally) A method to generate invoice number 
automatically 



Customer's initial data: 

1. Name, telephone number, address, e-mail address, etc. 

2. Fiscal year-end (possibly only for commercial accounts) 

3. Customer's bank account (s) 

4. Facilitator account or reference number 

5. Password to the subscriber service and/or to individual 
accounts 

6. Bill notification method (e.g., via e-mail) and address 
(e.g., an e-mail address) 

While e-mail notification is clearly a preferred option, the 
facilitator at its option may make available alternative 
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notification methods such as pager, text message on a cellular 
phone, or on-line access to the account on the facilitator's 
website. The system should enable any subscriber to update or 
correct the data of record at any time. In the case where a 
5 subscriber is both a biller and a customer, then various of the 
items of data listed above need be entered only once (e.g., the 
subscriber, if both a biller and customer, need have only one 
account with the facilitator, and the subscriber's bank account 
information need be entered only once) . 

10 

Expansion, modification and refinement of the system as 
described thus far are possible and may be desirable. For 
example, the use of intelligent agents on the Internet is known; 
the system could be set up so that a subscribing customer may 

15 utilize an intelligent agent facility to make payment to a 
biller. Such intelligent agent for example might identify the 
optimal way of making a payment (e.g., from the bank account with 
sufficient funds to make the payment, or by transferring funds 
from one of the customer's bank accounts to another to provide 

20 sufficient funds in a selected bank account to make the payment) . 

Other possible refinements include set-up of the system to 
enable the facilitator to generate reports for subscribers. 
Reports for the biller may include, for example, periodically 

25 generated aged lists of invoices, identifying those customers who 
have paid their outstanding invoices and those who have not. The 
facilitator may keep all transaction records available for on- 
line access for 6 months or for some suitable period after the 
biller' s fiscal year-end. Reports can also be made available to 

30 customer subscribers (e.g., lists within a reporting period of 
what has been paid to whom and what invoices remain unpaid) . 
Similarly, all customer transaction records may remain on-line 
until 6 months (say) after the fiscal year-end of the customer 
have elapsed, or until some specified time after the end of the 

35 calendar year. 
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Subscribers who are both a biller and a customer could also 
have on-line access to the following types of reports generated 
by the facilitator, among others: 

1. Reports showing billing and payments transactions in 
5 chronological order; 

2. Periodic cash flow analysis; 

3. Reports of interactions with other companies either 
generally or selectively. 

10 The description of the foregoing system is based on the 

presupposition that the facilitator, billers and customers have 
suitable computers or terminals with internet access via a 
suitable telecommunications link. The transactions described 
above are each individually transactions of types that 

15 conventionally occur on the internet; what is primarily 
advantageous and unique about the system described is the novelty 
of the interrelationship between facilitator, billers and 
customers (both those who are subscribers and those who are not) 
and especially the "open architecture" approach that permits, in 

20 a preferred embodiment of the system, any biller and any customer 
to use the system, whether they are subscribers or not. The 
hardware and software platform and structure used to implement 
any particular system according to the invention can be the same 
as or generally similar to those now used for operating and 

25 accessing any E-Commerce web site from which people can order 
products or services on-line and/or effect on-line payments 
(including making credit card payments) . 

Note that although the foregoing system as described is 
30 intended for internet use, it can be used in any suitable open- 
architecture telecommunications context. 

Summary of the Diagrams 

35 Figure 1 is a block diagram representing a conventional 
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(prior art) billing system used by a company to send individual 
invoices to individual customers. 

Figure 2 is a block diagram representing a conventional 
5 (prior art) direct biller system used by billers to distribute 
invoices to customers. 

Figure 3 is a block diagram representing a conventional 
(prior art) bill consolidator system used by companies to 
10 distribute payment information for customers. 

Figure 4 is a block diagram representing the 
relationship between multiple companies using the system to post 
invoices amongst themselves within a billing and payment system 
15 according to the present invention. 

Figure 5 is a flowchart representing a conventional 
(prior art) Internet-based invoice posting system and method, for 
use by a bill consolidator. 

20 

Figure 6 is a flowchart representing a preferred 
embodiment of an invoice posting and associated data gathering 
system and method according to the present invention. 

25 Figure 7 is a flowchart illustrating a conventional 

(prior art) Internet-based system and method for arranging an 
invoice payment by a customer, for use by a direct biller, or a 
by bill consolidator. 

30 Figure 8 is a flowchart representing a preferred 

embodiment of a system and method for invoice payment for use by 
a customer according to the present invention. 

Description of the Invention with Reference to the Diagrams 

35 
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The billings and payments facilitator system and method 
according to a preferred embodiment of the invention comprise an 
integrated system and method embodying the steps, apparatus and 
relationships manifest in both Figures 6 and 8. For convenience, 
the system and method have been divided into two parts, viz (i) 
invoice posting (Figure 6), and (ii) invoice review and payment 
(Figure 8) . For convenience in distinguishing the present 
invention from the prior art, Figures 1, 2, 3, 5 and 7 
respectively present prior systems and methods for direct billing 
(Figures 1 and 2), bill consolidation (Figure 3), invoice posting 
(Figure 5), and for invoice review and payment (Figure 7). 
Figure 4 represents a simplified presentation of the possible 
dual status of any given person (corporate, firm or individual) 
as being both a biller and a customer in a billing and payment 
system according to the invention. 

Referring to Figure 1, in a typical unilateral billing 
system, a given company (biller) creates invoices as goods are 
delivered or as services are rendered and sends individual 
invoices to individual customers. Such company creates a 
separate invoice for each of its customers. An invoice is then 
sent by the company directly to the customer. 

Referring to Figure 2, a given company may accumulate 
invoices for a given customer and send out a monthly or other 
periodic billing summary to the customer. As an alternative, the 
company may retain a billing service to look after its billings. 
In either case, a single billing entity creates a separate 
statement of account or equivalent for every customer and sends 
the pertinent statement of account, invoices, etc. to respective 
customers. The system is a conventional unilateral billing 
system in either case. 

Referring to Figure 3, a bill consolidator (say, a credit 
card company) collects invoices from various billers and sorts 
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them by customer, sending to each customer monthly a statement 
of what is owing to the bill consolidator to pay the set of 
billings received from various billers during the preceding month 
for that customer. There is no link between billers and 
5 customers; the billers' links are with the bill consolidator and 
the customers' links are with the bill consolidator. All billing 
information directed to a given customer is compiled by the bill 
consolidator in a single invoice or statement of account and sent 
to the customer. 

10 

By contrast with the foregoing, pursuant to the open- 
architecture concept of the present invention, any biller may, 
using the inventive system, electronically post an invoice 
intended for any customer. Any billed customer may pay any bill 

15 that has been directed to the customer via the system, without 
being a subscriber to the system. According to a preferred 
embodiment of the inventive system, the biller sends invoice data 
to a system facilitator at the latter' s website; the facilitator 
alerts the customer; and the customer using a bill identification 

20 code password or the like accesses the bill and may arrange 
direct electronic payment of same. Since, in contrast to billing 
consolidator systems, there is no requirement that the customer 
be a subscriber to the system, the system can be used by anyone 
who has the appropriate internet access. And in contrast to 

25 direct billing systems of the sort illustrated in Figures 1 and 
2, the open-architecture system according to the invention 
permits the biller to direct the biller' s invoice to a given 
customer and to have that customer pay that biller' s invoice; the 
system is multilateral, involving many billers and many 

30 customers. 

Figure 4 illustrates an important result of this "open 
architecture" internet-based billing and payment system according 
to the invention, viz that a given person (corporate, firm or 
35 individual) who uses the system is equally entitled to either 
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receive an invoice or post an invoice. Furthermore, a user may 
have multiple dealings with multiple customers and suppliers of 
its own. The "open architecture" of the system groups both 
customers and billers together into a single pool of users who 
may on one occasion be billers, on another customers. Of course, 
some may be billers only and some customers only, but the system 
is fully flexible as to the possibilities. 

Figure 5 illustrates a conventional Internet-based method 
of posting an invoice by a bill consolidator (a credit-card 
issuer is a typical bill consolidator) . The bill consolidator 
maintains a database S-l containing the requisite particulars of 
those billers whose billings to customers are accepted by the 
bill consolidator for passing on to a customer in a single 
integrated statement, typically a monthly statement. Such data 
will include, of course, a full identification of each biller, 
the biller' s address, account number, password if appropriate, 
etc., and any other particulars required by the bill consolidator 
for its records for the set of billers whom it serves. 

When a biller wishes to have an invoice paid, the biller 
provides invoice data to the website of the bill consolidator, 
who verifies the authenticity of the biller by comparison of the 
incoming data against the registered data in biller database S-l. 
If verification of the authenticity of the biller occurs, then 
the data sent by the accepted biller will necessarily include an 
identification of the customer to whom the invoice is to be 
presented. The bill consolidator maintains customer data for 
each of the bill consolidator' s customers in a database S-2. For 
each fresh invoice, the identification of the customer designated 
by the biller is compared with the data in the customer database 
S-2, and the authenticity of the customer is verified. Note that 
in this system, customers are direct customers of the bill 
consolidator; the transaction between biller and customer was 
completed when the customer presented a credit card (say) to the 
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biller for payment for goods or services provided by the biller 
to the customer. The remaining transactions are between biller 
and bill consolidator , on the one hand, and between bill 
consolidator and customer, on the other hand. The biller has no 
5 obligation to know the customer or anything about the 
creditworthiness of the customer beyond the fact that the 
customer has a credit card (say) . The customer database is 
generated by the bill consolidator as part of the bill 
consolidator' s business. 

10 

Assuming that the customer is properly verified as an 
accepted customer, appropriate details of the accepted invoice 
are posted on the bill consolidator ' s website. The bill 
consolidator periodically, or instantaneously once an invoice has 
15 been accepted, may post such invoice or a consolidation of such 
invoices on the website for access by the customer. The complete 
set of stored invoices is maintained in an invoice database S-3. 

The manner in which a customer conventionally pays a posted 
20 invoice that has been posted by a bill consolidator is reviewed 
further below with reference to Figure 7. 

By comparison, Figure 6 illustrates the manner of posting 
an invoice using the facilities of a billings and payments 

25 facilitator in accordance with the principles of the present 
invention. Figure 6 illustrates the on-line steps and system 
operative once a biller accesses the website on-line. The 
facilitator maintains a database S-4 of particulars of all of the 
billers whose invoices are accepted for website posting by the 

30 facilitator. Note that in Figure 5, the customer data within 
customer database S-2 is customer data typically maintained by 
the bill consolidator, and is normally not supplied separately 
by the biller to the consolidator. The biller merely has to 
identify the essential particulars of the customer for each 

35 invoice, such essential particulars typically comprising a name, 
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a credit card number, and a card expiry date. By contrast, the 
customer data in customer database S-5 in Figure 6 is typically 
provided entirely by the biller, and of course, is required to 
be updated from time to time as the biller' s customer list 
5 expands. 

When a biller wishes to post an invoice pursuant to the 
method of the present invention, the biller sends a message to 
this effect to the facilitator, who compares the biller 

10 identification input data with what is registered in the 
facilitator's biller database S-4. If the biller is identified 
and verified, the invoice is treated as that of an accepted 
biller; however, the invoice also identifies a customer, and the 
biller will have been obligated to provide the facilitator with 

15 suitable customer data on that same occasion, or on a previous 
occasion, which customer data is maintained in customer database 
S-5. If the customer's bill identification code is thus properly 
identified and verified according to the protocol established by 
the facilitator, then the invoice is treated as being one 

20 suitable for presentation to an accepted customer, and is posted 
for access by the customer (as will be more fully described with 
reference to Figure 8) . Particulars of all of the invoices that 
are posted are maintained in an invoice database S-6. 

25 Note that step 1 (identify biller) and step 2 (identify 

customer) can be accomplished without the need to process all of 
the data in the invoice; all that is required to be processed in 
steps 1 and 2 is biller and customer identification and 
verification. A "Verified" result at steps 1 and 2 permits full 

30 data relating to the invoice to be posted, but that additional 
data may be transmitted directly from the biller ' s incoming data 
stream to the invoice database S-6, and need not pass through 
verification steps 1 and 2. 

35 Data gathering step 4 insofar as it pertains to biller and 
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customer data may be the default first data storage step if the 
biller has not previously dealt with the facilitator and thus 
does not pass step 1 (biller identification and verification) ; 
otherwise step 4 is implemented for biller and customer data only 
5 if an updating of such information is required. A failure to 
obtain a "Verified" result at step 2 (customer identification and 
verification) would again invoke step 4 insofar as customer 
identification is concerned. Step 4 (posting invoice data) 
occurs only after a "Verified" result is obtained at both steps 
10 1 and 2. 

Referring to Figure 7, the flowchart reflects a sequence of 
invoice review and payment activities that occurs at a website 
operated by a direct biller or by a bill consolidator . A 

15 customer who has received an invoice accesses the website on-line 
and provides customer data (name, address, e-mail address, 
account number, password, etc.) sufficient to identify the 
customer according to the protocol established by the website 
operator. The website operator will typically have previously 

20 stored customer data as registered data in database S-2, and will 
compare the customer's identification data submitted on-line to 
what is registered for that customer in database S-2. If there 
is a match, then the customer on-line to the website is verified 
as an authentic customer (accepted customer) , and the website 

25 operator displays to the customer on-line a standard-form 
invoice, or a set of particulars for an invoice that is due for 
payment. This invoice data is obtained from an invoice database 
S-3 that correlates the accepted customer input data with stored 
invoice data associated with that accepted customer, so as to 

30 present to the customer the data associated with any invoices 
that are outstanding for payment. The customer has the 
opportunity to view the invoice data on screen, and if the 
customer does not accept that the invoice is payable, may either 
log off, or (depending upon the options available at the website) 

35 notify the website operator that the invoice is not accepted, in 
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which case, measures designed to remedy the problem would 
normally be invoked. However, if the customer accepts the 
invoice, then the website operator displays a screen, or screen 
fragment, that presents to the customer the option to pay the 
invoice by debiting the customer's bank account. Note that if the 
bill consolidator operating the website is a credit card company, 
that company may be a bank, and the bank account to be debited 
may of course be maintained by that same bank. 

Once payment is effected via this Internet transaction, the 
fact of payment is entered in the invoice database S-3 against 
the invoice in question, so that the invoice will be recorded 
thereafter as having been paid. 

By contrast, Figure 8 illustrates the series of steps 
required for customer bill payment when a bill payment 
facilitation system and method according to a preferred 
embodiment of the present invention is used. In this case, the 
website is operated by a billings and payments facilitator in 
accordance with the present invention. Figure 8 illustrates the 
on-line steps and system operative once a customer accesses the 
website on-line. 

The method reflected in Figure 8 is premised on a prior 
invoice posting in compliance with Figure 6, whereby billing data 
submitted to the facilitator's website has included accepted 
invoice details in respect of a fresh invoice, whereupon the 
facilitator has sent to the customer, preferably by e-mail, a 
message notifying the customer that a fresh invoice is available 
for viewing and payment, and communicating to the customer a bill 
identification code required to be submitted by the customer in 
order to view the invoice and arrange its payment. 

Before any such message is sent to the customer, the 
facilitator will have previously established that it has of 
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record sufficient data to identify and verify the customer in 
accordance with whatever protocol is established by the 
facilitator. The applicable customer data is stored in database 
S-5. 

5 

When a customer wishes to view a fresh invoice of which the 
customer has previously received notice, the customer accesses 
the facilitator's website on-line and submits to the facilitator 
the requisite customer identification data that can be compared 

10 with stored and registered data in database S-5 for those 
customers that are of record with the facilitator. The 
facilitator conducts a comparison between the input data and the 
stored data (step 1), and if the customer is identified and 
verified as one whom the facilitator is prepared to serve, the 

15 next step 2 in the on-line session occurs, namely, the comparison 
by the facilitator of the stored bill identification code for the 
invoice with that supplied by the customer. If the bill 
identification code is verified as authentic for a given invoice, 
then in step 3 the customer is able to view the invoice. Note 

20 that step 3 is implemented only if a "Verified" result follows 
from steps 1 and 2. 

If the customer does not accept the invoice, or does not 
wish to pay it, the customer may log off, or if the system so 

25 provides, the customer may send a message to the biller via the 
facilitator that the invoice is disputed or otherwise. If, 
however, the customer accepts the invoice for payment, the 
customer provides suitable payment instructions to the 
facilitator (step 5) after first analysing payment options (step 

30 4), if appropriate. (Sometimes a customer may have more than one 
account, or more than one means of payment that can be used, and 
this choice, if available, is presented to the customer in step 
4 as a prelude to instructing the facilitator to effect payment 
pursuant to step 5.) Once the appropriate method of payment has 

35 been elected, the customer submits to the facilitator this 
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payment information along with an instruction to pay the invoice, 
and the amount paid is credited against the invoice. The amount 
paid is credited to a selected one of the biller's bank accounts 
(bank accounts of both billers and customers being maintained in 
5 database S-7), less a transaction fee exacted by the facilitator. 

Database S-7 may be maintained directly by the bank or banks 

maintaining the accounts in question, with permitted access by 

the facilitator to arrange authorized debit and credit 
10 transactions in the bank accounts. 

Assuming that customers' bank accounts are maintained in 
database S-7, and that the customer may have more than one bank 
account (or other account with a financial institution of some 

15 sort, including credit card accounts), the various options 
available to the customer for paying the invoice may be presented 
at step 4 (analyse payment options) . Further, if the system so 
provides, an intelligent agent may, on the customer's behalf, 
sample data in various of the customer's accounts, and make a 

20 recommendation to the customer as to how to effect payment, 
including by way of transfer of sums of money from one customer 
account to another, if appropriate. 

Various embellishments of the systems of Figures 5-8 are 
25 possible, and normal encryption, authentication, anti-hacker and 
other peripheral system components and procedures would normally 
be invoked to ensure that the transactions to which these 
flowcharts apply are authentic, properly recorded and private. 

30 The invention is not limited to the preferred embodiment 

described, but is to be accorded the full scope set forth in the 
appended claims. 
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What is claimed is: 



1. An open-architecture billings and payments facilitation 
system for use with a telecommunications network and user- 
operated by means of computers. 

2. A system as defined in claim 1 wherein the 
telecommunications network is the Internet. 

3. A system as defined in claim 2 including an Internet- 
accessible website system interactive on-line with a 
multiplicity of billers and a multiplicity of customers. 

4- A system as defined in claim 3 wherein the website system 
includes means for posting invoices received from billers, 
means for alerting respective customers that invoices 
respectively directed to such customers have been posted, 
and means for displaying to such customers particulars of 
such posted invoices. 

5. A system as defined in any of the preceding claims wherein 
the website system includes means operable by customers to 
identify and pay discrete invoices posted, and means to 
transfer payment funds less applicable transaction fees to 
the respective billers. 

6. A method of posting and paying invoices via the Internet 
comprising: 

establishing an interactive website; 

maintaining at least one database including selected 
particulars of individual billers and individual customers; 
receiving data from billers relating to biller 
identification, customers of each biller, and particulars 
of each invoice rendered by a biller to a designated one of 
biller's customers; 
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posting data representing particulars of each invoice for 
access by the customer identified in the invoice; 
notifying such customer that an invoice has been posted; 
displaying the posted invoice to such customer upon receipt 
of such customer's verification of identity and right of 
access to the invoice; 

debiting an account identified by such customer for payment 
of such invoice; and 

transferring to a designated account of such biller the 
amount paid by the customer, optionally less a transaction 
fee. 

Barrigar & Moss 
Patent Agents for the Applicant 
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